Contact INFO Request

Function

This request is used to query the data of a Contact.

Requirements

The Contact must exist.

Features

You can only query data of Contacts administered by your own.

Request Parameters

A request comprises the parameters described below:

K/V Keyword	XML Namespace and Element	Occurrence min - max	Type / Length	Value Range	Description
Action	contact info	1	enumeration	Info-erule	request type
Version	-	1	enumeration	version-erule	This is the version. The keyword is only relevant for requests in the key/value format.
Handle	contact:handle	1	token 9 - 32	contact-rule	This is the unique ID of the Contact. Apply the following syntax: <RegAccId>-<ID of DENIC member>

Common Mistakes

The Contact handle stated in the request does not exist.

Examples

Example requests for PERSON or ORG

Copy

Response K/V Contact INFO

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
Handle: DENIC-1000002-MAX
Type: Person
Name: Max Mustermann
Address: Business Services
Address: Theodor-Stern-Kai 1
Address: The maximum number of
Address: address lines is five and
Address: one line may be 255 characters long.
PostalCode: 60596
City: Frankfurt am Main
CountryCode: DE
eMail: email-1@denic.de
eMail: email-2@denic.de
eMail: email-3@denic.de
eMail: email-4@denic.de
eMail: email-5@denic.de
eMail: email-6@denic.de
Phone: +49.6927235x290

[VerificationInformation]
VerifiedClaim: name
VerifiedClaim: address
VerificationResult: success
VerificationReference: ABC123/45GHT
VerificationTimestamp: 2023-11-11T15:36:21+02:00
VerificationEvidence: idcard
VerificationMethod: auth
TrustFramework: de_denic

[VerificationInformation]
VerifiedClaim: email
VerificationResult: failed
VerificationReference: 354546TZQ
VerificationTimestamp: 2023-10-04T12:22:19+02:00
VerificationEvidence: transaction_log
VerificationMethod: auth
TrustFramework: de_denic

Copy

Contact INFO XML

38
39
40
41
42
43
44
45
46
47

<?xml version="1.0" encoding="UTF-8"?>
<registry-response xmlns="http://registry.denic.de/global/5.0"xmlns:tr="http://registry.denic.de/transaction/5.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<tr:transaction>
  <tr:stid>2e6d8093-9f12-11df-996c-33039fab005f</tr:stid>
  <tr:result>success</tr:result>
  <tr:data>
    <contact:infoData xmlns:contact="http://registry.denic.de/contact/5.0">
      <contact:handle>DENIC-99995-JOHNDOE</contact:handle>
      <contact:type>PERSON</contact:type>

The structure in the XML document after “Person” is identical to the structure of a request with the RRI protocol 4.0 and can be adopted from there.

Copy

Contact INFO XML

48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
      <verification:verificationInformation xmlns:verification="http://registry.denic.de/verification/5.0" xsi:type="verification:verificationInformationType">
        <verification:verifiedClaims>
          <verification:claim>address</verification:claim>
          <verification:claim>name</verification:claim>
        </verification:verifiedClaims>
        <verification:verificationResult>success</verification:verificationResult>
        <verification:verificationReference>ABC123/45GHT</verification:verificationReference>
        <verification:verificationTimestamp>2023-10-04T12:22:19+02:00</verification:verificationTimestamp>
        <verification:verificationEvidence>idcard</verification:verificationEvidence>
        <verification:verificationMethod>auth</verification:verificationMethod>
        <verification:trustFramework>de_denic</verification:trustFramework>
      </verification:verificationInformation>
      <verification:verificationInformation>
        <verification:verifiedClaims>
          <verification:claim>address</verification:claim>
          <verification:claim>name</verification:claim>
        </verification:verifiedClaims>
        <verification:verificationResult>success</verification:verificationResult>
        <verification:verificationReference>354546TZQ</verification:verificationReference>
        <verification:verificationTimestamp>2023-10-04T12:22:19+02:00</verification:verificationTimestamp>
        <verification:verificationEvidence>transaction_log</verification:verificationEvidence>
        <verification:verificationMethod>auth</verification:verificationMethod>
        <verification:trustFramework>de_denic</verification:trustFramework>
      </verification:verificationInformation>

The structure in the XML document before “contact:infoData” is identical to the structure of a request using the RRI protocol 4.0 and can be adopted from there.

Copy

Contact INFO XML

72
73
74
75
    </contact:infoData>
  </tr:data>
</tr:transaction>
</registry-response>

Data object for PERSON and ORG

K/V Keyword	XML Namespace and Element	Occurrence min - max	Type / Length	Value Range	Description	Policy
Handle	contact:handle	1	token 9 - 32	contact-rule	This is the unique ID of the Contact.Syntax: <RegAccId>-<MemberID >	A Contact handle must always start with the RegAccId of the administering RegAcc.
Type	contact:type	1	enumeration	role-erule	These Contact types are available: PERSON = natural person, ORG = a legal person (company, association, grouping of holders, organization etc., such as "DENIC eG")	The type of contact can be changed later. For Holder you may only use the types PERSON or ORG.
Name	contact:name	1	normalizedString 1 - 255	name-rule	This is the Contact's name.	Once set, you cannot change the keyword "name" any more.
Organisation	contact:organisation	0 - *	normalizedString 1 - 255	organisation-rule	This is the organisation which is represented by the Contact.	You may only use the types PERSON. Cannot be changed, if the domain bears a DISPUTE entry. You must always state the domain holder in the "Name:" field. The "Organization" value has no right to the domain and is not entitled to apply for an AuthInfo or a provider change or similar.
Address	contact:address	1 - *	normalizedString 1 - 255	address-rule	Street and house number of Contact	The keyword cannot be changed if the Contact is referenced as the holder of a domain which bears a DISPUTE entry.
PostalCode	contact:postalCode	1	token 1 - 20	postalcode-rule	Postal code and address of Contact	The keyword cannot be changed if the Contact is referenced as the holder of a domain which bears a DISPUTE entry.
City	contact:city	1	normalizedString 1 - 80	city-rule	Place of residence of Contact	The keyword cannot be changed if the Contact is referenced as the holder of a domain which bears a DISPUTE entry.
CountryCode	contact:countryCode	1	Enumeration 2	country-erule	Country code of the country in which the Contact's place of residence is located	You must use the country code of the ISO-3166-1 alpha-2 list ISO-3166-1 alpha-2 Liste. The keyword cannot be changed if the Contact is referenced as the holder of a domain which bears a DISPUTE entry.
Email	contact:email	1 - *	normalizedString 3 - 255	email-rule (see RFC5322 - Internet Message Format)	E-mail address of Contact	„email” always is a mandatory field and must be specified at least once for the types PERSON and ORG in Contact CREATE and Contact UPDATE requests

K/V Keyword	XML Namespace and Elements	1st Nesting	2nd Nesting	Occurrence, min – max per verification information block	Type / Length	Value Range	Description
[VerificationInformation]	<verification:verificationInformation xmlns:verification="http://registry.denic.de/verification/5.0" xsi:type="verification:verificationInformationType"> <verification:verifiedClaims> <verification:verificationResult> <verification:verificationReference> <verification:verificationTimestamp> <verification:verificationEvidence> <verification:verificationMethod> </verification:verificationInformation>	-	-	Once per verification record	-	-	For K/V: header line that precedes the verification record
-	-	<verification:verifiedClaims> <verification:claim> </verification:verifiedClaims>	-	-	-	-	-
VerifiedClaim	-	-	<verification:claim> ... <verification:claim>	1 - 3	normalizedString / fixed length due to predefined valued	claim-rule	"claims" are data that has been verified Special features for e-mail The complete verification information block with all keywords or XML elements and values must be specified for an email, if the result of the email check was negative, in other words, the value is ‘failed’. A subsequent update with the positive value ‘success’ must also be communicated, after a fail. If the value ‘success’ was present at the start of the check, the verification information block for email can be reported.
VerificationResult	-	<verification:verificationResult> ... </verification:verificationResult>	-	1	normalizedString / fixed length due to predefined valued	result-rule	Notification of the verification result
VerificationReference	-	<verification:verificationReference> ... /verification:verificationReference>	-	1	normalizedString / ength is defined by member	reference-rule	The content is free text that makes reference to a request number or order number, etc.
VerificationTimestamp	-	<verification:verificationTimestamp> ... </verification:verificationTimestamp>	-	1	date-time	timestamp-rule	Point in time, when the verification was performed
VerificationEvidence	-	<verification:verificationEvidence> ... </verification:verificationEvidence>	-	1	normalizedString / fixed length due to predefined valued	evidence-rule	Evidence that was checked within the scope of the verification (e.g. for the value "idcard", which corresponds to identity card)
VerificationMethod	-	<verification:verificationMethod> ... </verification:verificationMethod>	-	1	normalizedString / fixed length due to predefined valued	method-rule	Method used to carry out the verification (e.g. for the value "pvr", which stands for evidencing via "video identification")
TrustFramework	-	<verification:trustFramework> ... </verification:trustFramework>	-	1	normalizedString / fixed length due to predefined valued	framework-rule	Framework used for the verification At present, only the value "de_denic" exists, others may follow later.

Data object REQUEST

K/V Keyword	XML Namespace and Element	Occurrence min - max	Type / Length	Value Range	Description	Policy
Handle	contact:handle	1	token 9 - 32	contact-rule	This is the unique ID of the Contact.Syntax: <RegAccId>-<MemberID >	A Contact handle must always start with the RegAccId of the administering RegAcc.
Type	contact:type	1	enumeration	role-erule	REQUEST = an e-mail address or a URL in the URI-Template format.	For General Request and Abuse Contact you may only use the type REQUEST.
URI-Template	contact:uri-template	1	normalizedString 8 - 1024	Syntax as defined in RFC 6570 - URI Template	The variables Ulabel and Alabel in the URI-Template are replaced with the domain at a domain query (web-whois).	In case of a CREATE request, the content of the URI-Template is converted into a URL or e-mail as a test (For Alabel and Ulabel, a sample domain is used.) to check the syntax on correctness.

Contact INFO Request

Examples

Thank You!

Thank your for your feedback.